home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
Language/OS - Multiplatform Resource Library
/
LANGUAGE OS.iso
/
tcl
/
workshop
/
tcl93pr1.lha
/
tcl93-proceedings2
/
futures
/
session3
< prev
next >
Wrap
Text File
|
1993-07-03
|
7KB
|
151 lines
This article was slightly edited for spelling by lvirden@cas.org by
request of the author.
Newsgroups: comp.lang.tcl
Path: chemabs!malgudi.oar.net!caen!saimiri.primate.wisc.edu!ames!agate!pasteur!sprite.berkeley.edu!asah
From: asah@sprite.berkeley.edu (Adam Sah)
Subject: Tcl'93 Future Directions Session 3 notes.
Message-ID: <1993Jun13.184606.12638@pasteur.Berkeley.EDU>
Sender: nntp@pasteur.Berkeley.EDU (NNTP Poster)
Nntp-Posting-Host: treason.berkeley.edu
Organization: University of California, at Berkeley
Date: Sun, 13 Jun 1993 18:46:06 GMT
Lines: 133
What follows are notes I made during the "Future Directions" session #3,
led by John Ousterhout, during the Tcl'93 Workshop. Each session had a
"main topic" of discussion, plus an open period where he solicited random
suggestions for improving the language.
Main topic: security.
---------------------
I. John's slides (these are more or less verbatim from his slides- the
peanut-gallery commentary is at the bottom)
1. Evaluating Untrusted Scripts - cover
2. Introduction
goal: use tcl scripts as a gen. purp. method of interchange:
- among app's on a display.
- active email (eg. surveys)
security problems:
- tcl is powerful (file access)
- evil scripts can do great harm.
solution:
- twin interpreters (like user/kernel space in os's)
- protected calls between them (like system calls)
3. Twin Interps
- trusted interp- used by app/user: has full access to all tcl cmds
- untrusted interp- used to exec incoming (suspicious) scripts- all
dangerous cmds removed.
- new cmds in trusted interp:
set evil [safetcl create]
$evil eval $script
- untrusted interp won't be able to do much that's useful, though.
4. Safe Calls
Allow untr. interp to impl. restr'd new fun's for untr. interp:
- restr'd file access, sending mail...
- analogous to system calls.
Mechanism: cmd in untrusted interp that causes exec of cmd in trusted
interp.
- in trusted interp:
set evil [safetcl create]
$evil safecall sendmsg checksend
- in untr'd interp:
sendmsg $to $body
- subst's must occur in untr'd interp!
- checksend exec'd in tr'd interp with fully-subst'd args.
- result/error retn'd to untr'd interp.
5. Safe Calls (cont'd)
Proc's that impl. safe calls must be very careful:
- never eval arg as tcl script or tcl expr!
- check filenames before read/write files.
- never exec shell cmds specified in args w/o careful checking first.
- when in doubt, ask user for permission (but not too much, or else this
technique loses effectiveness, as users are constantly saying "OK"
to everything)
result: safe calls hard to write and certify.
but, for max power, wants lots of safe calls avail.
need mechanism for certifying and distributing safe calls.
6. Certifying Safe Calls
Use encryption techniques (digital sigs):
- central, trusted, netw auth. writes new safe calls, certifies them
with dig. sig, distr's publicly.
- anyone can fetch cert'd safe calls, check sig, install locally w/o fear.
- active email msg (untr'd) can contain new safe calls as part of
untr'd script.
- untr'd script invokes existing safe call to make new safe call
- in tr'd interp, verify sig of incoming safe call before installing.
Can extend mech. to have local cert. auth's as well as global.
7. Other apps
Safe Call mech. suitable for many other things besides active email:
- restrict incoming 'send' cmds in tk.
- in commercial product, restrict access by customers to internal cmds.
- in device control apps, don't allow users total control over devices
(could be dangerous)
II. Comments (where possible, I made a note of who said what, so followup is
possible- if no name is present, then it means that I didn't catch the
speaker quickly enough...)
John: example of GUI for untrusted Tk apps: have untrusted windows be
children of trusted windows in Tk- then add speckled border to mean "don't
trust me!", plus a 'kill' button that always gets rid of window (which
would also handle the 'grab' problem...)
- resource limits on untrusted interp? (ie. disk, cpu, mem usage?)
- John: safety is more important than resource limits (which most OS's
still handle ok w/o security holes)
- Karl: _never_ call eval on stuff from untrusted script (based on his
implementation)
- John: must strip _all_ I/O (otherwise untrusted script could generate
it's own file handle, etc.)
==> ok to make untrusted interp separate process (the argument
that file handles aren't valid across process boundaries
isn't valid- you wouldn't want to give away real file
handles anyway)
- Adam: important to have test suites for security- won't stop new
holes, but will stop old and common holes from appearing as a result of
new features/changes.
- active email can install new safecalls- safe calls can be
"autoloaded" from a well-known site storing them (via email)- ie. in
active email, if a msg is dependent on a safecall not installed locally, you'd
get a "waiting for script..." msg and the new script could be telnet'd,
ftp'd, or email'd...
- need multiple levels of trust (alternate trusted sites and sources)
- experiences from MIME- the 1st released version must be good enough,
because commercial sites might not be able to receive these updates.
good enough= useful for 99% of all stuff, ie. active msgs.
- auditing/logging of active email etc.?
- Adam: have an _unsafe_ call library, not just a safe call lib-
question of whether it makes more sense to have large libraries of safe
calls, or large lib's of unsafe calls (latter will be slower to exec,
since need checking, but former are more prone to sec leaks and need
verification etc.)
- templates for active email (a standard form called a "survey" and
users can declare options for how it will look and behave within that
style).
misc:
- Wayne Christopher: hard to debug 'trace' if there's an error in the
trace procedure. someone: use "after 1" to get you out of that.
- can't rerun error msgs.
- need: error msg after write traces.
- need: access to value _before_ write traces. John: diff to impl.
- an "unknown" for variable access.
- use of % subst in var traces
- events on all sorts of error (user defined events).
userdef error codes (long discussion on how to implement.
John suggests that the numeric error codes could be generated
at runtime by a routine, rather than by #defines.
Adam: be careful- they then can't be passed to
other wish's! John: string error codes?
- rename as an event?, return callbacks for procedures?
- pass args by name not position to proc's?
Thanks again,
-A.Sah'93 ...Adam Sah...asah@cs.Berkeley.EDU...
It's not the voltage, it's the amperage.